Hi Michael,
No that isn't really correct at all. You added the entire loop into the other loop and forgot to add the InLimit function.
Please read this post and see if it helps.
The Softlimits also had a small helper function (subroutine) that is called which returns whether we are in the limits or not. That function is called InLimit as shown below. You for got to copy that into your Init.c program which is why the Compiler is complaining that the InLimit funtion is not defined anywhere. Copy the code below to the very end of your Init.c file. C programs consist of "Functions" which you might think of as subroutines or sub-programs. There is one special function called "main" which is the first function that gets executed to start everything off. It may or may not then call other functions. Please try to merge the two programs again. If you can't get it I will do it for you but it would be helpful for you to understand this. Note I also removed the WaitNextTimeSlice() from the InLimit routine
because the main "for" loop already had a wait and we don't want two waits in the loop.
Regards
TK
int InLimit()
{
return ch0->Dest < XMINUS || ch0->Dest > XPLUS ||
ch1->Dest < YMINUS || ch1->Dest > YPLUS ||
ch2->Dest < ZMINUS || ch2->Dest > ZPLUS;
}
Group: DynoMotion |
Message: 4575 |
From: Michael Rosenfield |
Date: 4/17/2012 |
Subject: Re: soft limits |
Tom, Here is the latest version. I took out the MPG stuff, since it isn't complete anyway, which simplifies the code structure. It compiles without errors, but the axes are always out of limits. It also appears I stuck in an extra "int InLimit()" up at the beginning of the program - will this cause problems? The min/max definitions - are those encoder counts, or inches, or some other value? Where does Dest come from? Are these limits supposed to work for jogging? Is there a way to test these functions in KMotion, or do I run KMotionCNC and run the init function? Thanks, Michael
Group: DynoMotion |
Message: 4576 |
From: Tom Kerekes |
Date: 4/17/2012 |
Subject: Re: soft limits [1 Attachment] |
Hi Michael,
Very good! That looks correct.
The extra int InLimit(); is correct and good. A C compiler is a "one pass" compiler that reads through the file from beginning to end one time and is able to completely compile the program (pretty amazing really). So that extra line is called a function declaration which tells the compiler early on that there is a function called InLimit that returns an integer result. It is the same as the function except there is no body, just a semicolon. You can avoid the need for function declarations if you always put the function before anywhere that it is used, but most programmers like to put them at the end or some other more logical order.
The units are encoder counts. So instead of a number like you have of 12 it would be 12000 or 12 x your Resolution.
The ch0->Dest is where axis 0 is currently commanded to be. ch0 points to a data structure for the X axis. ch0->Dest is the way in C to reference the Dest variable within the ch0 structure.
You can move an axis in KMotion.exe using the console screen with Move or Jog commands. Or you can use KMotionCNC
The problem you are having is probably because when we initialize the axes we are careful to keep the encoder position. We command the Destination to be the same as the Encoder position reads back. We do this so we can recover after something like an Amplifier fault without any loss in position. Unfortunately if the Encoder position is in the limit then we can never re-initialize and move out of the limit. I added a feature to disable Soft Limits if Vitrtual Bit 48 is set. If you go to the Digital IO screen and set bit48 you should then be able to Initialize, move back out of the limits, then clear bit 48 to re-enable soft limits. See Attached.
Regards
TK
Group: DynoMotion |
Message: 4577 |
From: Michael Rosenfield |
Date: 4/17/2012 |
Subject: Re: soft limits [1 Attachment] |
Thanks, Tom! Maybe I'm setting the limits incorrectly? I loaded the init file without soft limits, and then I homed the axes, so the machine position was valid. (I was using the limits commented out in the file I attached last time, so x went from 0 - 603540). Then I loaded the init file with soft limits, and ran it, only to have all 3 axes shut off. What I really would like to accomplish is to have the machine never move into the limits, rather than disable the axes. Is this doable? Regards, Michael
Group: DynoMotion |
Message: 4578 |
From: Tom Kerekes |
Date: 4/17/2012 |
Subject: Re: soft limits |
Hi Michael,
It seemed to work for me. However you may want to open up your range slightly. If any axis is homed to zero then it will be servoing about zero which would include small negative numbers such as -1 counts which would immediately trip the InLimit. Look at the Axis Screen and verify the Axis positions are well within your allowed range before running your Init.c with Soft Limits.
No we don't have a means of preventing motion into the limits.
Regards
TK
Group: DynoMotion |
Message: 4579 |
From: Michael Rosenfield |
Date: 4/17/2012 |
Subject: Re: soft limits |
Ok, I will try that in the morning. Now I am looking at the MPG software again. In MPGsmooth, WaitNextTimeSlice(); is in there twice. I thought this wasn't allowed? What is the return 0 at the end for? How would this code get integrated with the init code with softlimits? Thanks, Michael
Group: DynoMotion |
Message: 4581 |
From: Tom Kerekes |
Date: 4/17/2012 |
Subject: Re: soft limits |
Hi Michael,
Hmmm you are correct. The first WaitNextTimeSlice() ; should be removed. It isn't that it isn't allowed it is that it wil cause the loop to loop at half the rate. Not a disaster, just sub-optimal.
I don't know how to describe adding something to an existing loop better than I tried here (did you read it)?
The return 0; at the end of the main function means that the main function will return 0 to it's caller when it returns to stop executing. The value isn't used (in fact in this case the return never happens) and isn't important.
Regards
TK
Group: DynoMotion |
Message: 4582 |
From: Michael Rosenfield |
Date: 4/17/2012 |
Subject: Re: soft limits |
Yes, I did read it. The extra WaitNextTimeSlice was confusing, as is combining the two different returns. I gave it a shot - how does this look? Regards, Michael
Group: DynoMotion |
Message: 4583 |
From: Tom Kerekes |
Date: 4/18/2012 |
Subject: Re: soft limits [1 Attachment] |
Hi Michael,
Don't really see where you were going there...
I've merged it the way I was thinking attached.
Regards
TK
Group: DynoMotion |
Message: 4585 |
From: Michael Rosenfield |
Date: 4/18/2012 |
Subject: Re: soft limits [1 Attachment] |
Thanks! Now, in the code supplied, MPGsmooth, the code for the MPG follows a WaitNextTimeSlice. But in the code you sent me, it is not. Why the difference? Regards, Michael
Group: DynoMotion |
Message: 4587 |
From: Tom Kerekes |
Date: 4/18/2012 |
Subject: Re: soft limits |
Hi Michael,
The idea is to have one WaitNextTimeSlice somewhere in the loop so the loop is executed one time per CPU time slice. See:
To understand things better you should pretend to be the computer (KFLOP) and execute the program sequentially line by line. When you come to a function call like InLimit() you will then jump to begin executing sequentially in the InLimit function. A "return" is what causes the computer to return to the main program where we last jumped out. It is like having a list of tasks to perform where one of the items in the list is to perform another list of tasks. After the "other" list is finished we should go back (return) to where we were in the main list. The return statement can just return to the calling program or it can optionally return and pass back some information in the form of a result. If you did this you would have realized that in
the last program you sent a large block of code was placed after the return statement in InLimit and therefore would be impossible to be ever executed.
Regards
TK
Group: DynoMotion |
Message: 4588 |
From: mrosenfield@hotmail.com |
Date: 4/18/2012 |
Subject: Re: soft limits |
That all makes sense. Like I said, I'm rusty on the C terminology, and I'm used to assembly programming syntax. So I installed the latest version this morning, and it seems to work. A bit clumsy to recover from out-of-limit, but maybe I need to approach it from another angle (like testing the G code instead). Since 4.29 is released, I tried installing and flashing that, but it was a disaster. I didn't have time to write down all the errors, but it wouldn't execute the init file (something about invalid thread), and the pc dropped communication with the KFlop. Reboot! wouldn't work; had to cycle the power. Reflashed 4.28, and went back to the 4.28 software, and everything is happy again. I have meetings until this afternoon, and then I can get more specific details. Any problem with having 4.28 and 4.29 present on the pc at the same time? Regards, Michael Sent from my Verizon Wireless Phone -----Original message----- From: Tom Kerekes <tk@...> To: "DynoMotion@yahoogroups.com" <DynoMotion@yahoogroups.com> Sent: Wed, Apr 18, 2012 15:51:51 GMT+00:00 Subject: Re: [DynoMotion] soft limits
Hi Michael,
The idea is to have one WaitNextTimeSlice somewhere in the loop so the loop is executed one time per CPU time slice. See:
To understand things better you should pretend to be the computer (KFLOP) and execute the program sequentially line by line. When you come to a function call like InLimit() you will then jump to begin executing sequentially in the InLimit function. A "return" is what causes the computer to return to the main program where we last jumped out. It is like having a list of tasks to perform where one of the items in the list is to perform another list of tasks. After the "other" list is finished we should go back (return) to where we were in the main list. The return statement can just return to the calling program or it can optionally return and pass back some information in the form of a result. If you did this you would have realized that in
the last program you sent a large block of code was placed after the return statement in InLimit and therefore would be impossible to be ever executed.
Regards
TK
| | | | | | | | | | | | | | | | | | | | | | | |